In some cases of software testing, functional requirements may include testing one or more event-pairs having a large time delay between a triggering event and a triggered event. An example of this could be a situation where a contractor, once on-boarded, is to be automatically terminated at the end of 60 days unless extended by a manager. Here, the hiring of the contractor may be considered the triggering event and the auto-termination, the triggered event. In order to test this code functionality, a straight line temporal software testing mechanism may be used wherein the test time units are mapped 1:1 to the wall clock time. In other words, if there is a Delay of 60 days between two events which are to be tested, the test project shall span 60 days.
To reduce the time taken to test delay based software, a time scale factor may be used. For example, a time scale factor of 1 day=1 minute may be employed to test the code. To implement this, a development team may change the code to manifest the delay into an updated condition. For example, to test a 60 day delay, the development team may make adjustments to the code to test for a 60 minute threshold, since 1 day is scaled to 1 minute. Post successful completion of the test, the development team may need to change the code back to the original code without the scaled time effect. For example, the delay is set back to 60 days instead of 60 minutes.
In this approach, once the testing is over, the additional code that was introduced for scaling the time factor is removed. This may not be ideal as such modifications may affect the reliability/functionality of the original code. Since developers are changing and re-changing the code base, a regression test re-run may need to be performed after each change. Consequently, a regression test may be required post functional testing. A regression test may be expensive, both in terms of time and resource.